| # AWT Enhancements in the JavaTM 2 SDK, v1.3 | Documentation Contents

> Version 1.3 of the Java 2 SDK includes the following AWT enhancements:

> > Multiple Monitor Support
> > New Class `java.awt.Robot`
> > New Event Masks for PaintEvents and InvocationEvents
> > Paint Coalescing
> > Printing API Enhancements
> > New Event Type for Tracking Changes to Component Hierarchies
> > AWT Native Interface

> Multiple Monitor Support

> > You can now render on multiple screens by creating `Frame`, `JFrame`, `Window`, or `JWindow` objects with the `GraphicsConfiguration` of the target `GraphicsDevice`.

> > The new `Frame` constructor, `Frame(GraphicsConfiguration)`, enables creation of a `Frame` object on a different screen device.

> > The new `Window` constructor, `Window(Window, GraphicsConfiguration)`, constructs a new invisible window with the specified window as its owner and the `GraphicsConfiguration` of a screen device.

> > The new `GraphicsConfiguration` `getBounds` method returns the bounds of the `GraphicsConfiguration` in device coordinates. If you have a virtual device, then the device coordinates returned from `getBounds` are virtual device coordinates.

> > Finally, the new `Component` `getGraphicsConfiguration` method returns the `GraphicsConfiguration` with which the `Component` was created.

> > In a virtual device configuration consisting of more than one physical screen device, the `GraphicsConfiguration` objects' coordinates are relative to the virtual coordinate system. For this reason, virtual coordinates must be used when calling the `setLocation` method of a `Frame` or `Window`. Similarly, calling `getBounds` of a `GraphicsConfiguration` in a virtual device environment returns virtual device coordinates.

> > The following code sample creates a `JFrame` object for each `GraphicsConfiguration` on each screen device in the `GraphicsEnvironment`. It offsets the coordinates of the intended location of the `JFrame` with the bounds of the `GraphicsConfiguration` to ensure that the `JFrame` appears on the screen of the specified `GraphicsConfiguration`.

> >             GraphicsEnvironment ge = GraphicsEnvironment.
> >                                      getLocalGraphicsEnvironment();
> >             GraphicsDevice[] gs = ge.getScreenDevices();
> >             for (int j = 0; j < gs.length; j++) {
> >                 GraphicsDevice gd = gs[j];
> >                 GraphicsConfiguration[] gc = gd.getConfigurations();
> >                 for (int i=0; i < gc.length; i++) {
> >                         JFrame f = new JFrame(gs[j].getDefaultConfiguration());
> >                         Canvas c = new Canvas(gc[i]);
> >                         Rectangle gcBounds = gc[i].getBounds();
> >                         int xoffs = gcBounds.x;
> >                         int yoffs = gcBounds.y;
> >                         f.getContentPane().add(c);
> >                         f.setSize(300, 150);
> >                         f.setLocation((i*50)+xoffs, (i*60)+yoffs);
> >                         f.show();
> >     	    }
> >     	}

> > If the bounds of a `GraphicsConfiguration` is not taken into account in this sample, a `JFrame` would appear at location (i*50, i*60) on the primary screen, which might be different than the screen of the specified `GraphicsConfiguration`.

> > For more information on how the Java 2D API supports multi-screen environments, see Rendering in a Multi-Screen Environment in the Programmer's Guide to the Java 2D API.

> New Class `java.awt.Robot`

> > New class `java.awt.Robot` has been added to the JavaTM 2 Platform. The Robot API is designed to make automated AWT and Swing testing possible. The Robot API allows code written in the Java programming language to generate low-level native mouse and keyboard input events. Because the events are generated at the operating system level (as opposed to the Java event queue or component level), they are indistinguishable from real user input to the rest of the AWT (both the native and Java-language portions).

> > Though designed to improve testability, the Robot API also provides other benefits:

> > - Accessibility enabled applications will be able to give more feedback. For example, if the user acts on a screen object using voice commands, the mouse pointer can be moved to indicated the object being manipulated.
> > - Enables the creation of computer-based training (CBT) and other demo type Java applications.

> New Event Masks for PaintEvents and InvocationEvents

> > The new final static fields `PAINT_EVENT_MASK` and `INVOCATION_EVENT_MASK` have been added to class `AWTEvent`. These fields are now available for use by `addAWTEventListener()` to allow client applications to listen for paint events and invocation events.

> Paint Coalescing

> > Painting performance has been enhanced through the implementation of paint coalescing. Areas that require repainting are now coalesced into a single, non-rectangular repaint area as they are posted to the event queue. This has the effect of batching repaints, executing multiple repaints simultaneously. Previously, paint events were queued up and executed in succession, even when the repaint areas overlapped.

> Printing API Enhancements

> > Two new classes have been added to package `java.awt.print`:
> > - `JobAttributes`
> > - `PageAttributes`
> > Class `JobAttributes` controls properties of a print job such as destination, number of copies, page ranges, etc. Class `PageAttributes` controls attributes of a printed page such as paper size, orientation, print quality, etc.

> > These classes are used by a new method in class `java.awt.Toolkit`:

> > > `getPrintJob(Frame, String, JobAttributes, PageAttributes)`

> > See Java AWT: Printing for more information on the printing API.

> > Support for using attributes will be added to the printing API in a future release of the Java platform.

> New Event Type for Tracking Changes to Component Hierarchies

> > Several new classes have been added to the Java 2 Platform to provide a standardized way for components to track changes to their component hierarchy. The new API is a preferred alternative to that provided by `javax.swing.event.AncestorEvent`
> > - displayability - whether a component has a peer
> > - show state - whether a component is showing on the screen
> > - ancestors additions to and deletions from the hieracrhy
> > - ancestor resizes
> > - ancestor moves
> > The new classes and interfaces implementing the new event types are:
> > - `java.awt.event.HierarchyEvent`
> > - `java.awt.event.HierarchyListener`
> > - `java.awt.event.HierarchyBoundsListener`
> > - `java.awt.event.HierarchyBoundsAdapter`
> > The following methods have been added to `java.awt.Component`:
> > - `addHierarchyListener`
> > - `removeHierarchyListener`
> > - `addHierarchyBoundsListener`
> > - `removeHierarchyBoundsListener`
> > - `processHierarchyEvent`
> > - `processHierarchyBoundsEvent`
> > The following fields have been added to `java.awt.AWTEvent`:
> > - `HIERARCHY_EVENT_MASK`
> > - `HIERARCHY_BOUNDS_EVENT_MASK`
> > Class `java.awt.AWTEventMulticaster` now implements interfaces `HierarchyListener` and `HierarchyBoundsListener`. In addition, it has the following new methods:
> > - `hierarchyChanged`
> > - `ancestorMoved`
> > - `ancestorResized`
> > - `add(HierarchyListener, HierarchyListener)`
> > - `add(HierarchyBoundsListener, HierarchyBoundsListener)`
> > - `remove(HierarchyListener, HierarchyListener)`
> > - `remove(HierarchyBoundsListener, HierarchyBoundsListener)`

> AWT Native Interface

> > The AWT Native Interface is a new interface for integrating native rendering engines with the Java 2 platform. The AWT Native Interface lets you design UIs with natively rendered components for best rendering performance.

> > In the most common usage, four steps are involved:

> > 1. Define a class that extends a Canvas .
> > 2. Declare the `paint` method as native and load its shared library in the static block.
> > 3. Use javah to generate a C/C++ header file for the native paint method. (See javah documentation for Win32 and Solaris platforms.)
> > 4. Write the native paint method and build it as a shared library.
> > Header files associated with the AWT Native Interface are in the SDK's `include` directory. They are
> > - `include/jawt.h` on both Win32 and SolarisTM platforms
> > - `include/win32/jawt_md.h` in the Win32 SDK only
> > - `include/solaris/jawt_md.h` on Solaris SDK only
> > These headers are not part of the official specification of the Java 2 Platform. The headers are provided as a convenience to developers who want a standardized way to access native drawing functionality.

> > For further information and sample code, see The AWT Native Interface.

Copyright © 1999 Sun Microsystems, Inc. All Rights Reserved. Please send comments to: java-awt@java.sun.com |